Entities often generate and use data that is important in some way to their operations. This data can include, for example, business data, financial data, and personnel data. If this data were lost or compromised, the entity may realize significant adverse financial and other consequences. Accordingly, many entities have chosen to back up some or all of their data so that in the event of a natural disaster, unauthorized access, or other events, the entity can recover any data that was compromised or lost, and then restore that data to one or more locations, machines, and/or environments.
Systems, hardware, computer-readable media, and methods for performing federated backups have proven useful in environments where it is desired to back up all databases in a defined group using a single save set for all the nodes in that group. Nonetheless, there remain some unmet needs where federated backups are concerned.
One example of shortcomings in the area of federated backups relates to the priorities set forth in a preferred server order list (PSOL) that specifies database copies eligible to be used for the federated backup, and the effect of those priorities relative to the active and passive databases residing on the various nodes. For example, depending upon the number of nodes in a group, and the number of databases distributed across those nodes, implementation of PSOL priorities can give rise to circumstances where fewer than all the nodes in the group are utilized for storage of the database backups. In such circumstances then, the backup workload is not efficiently distributed among the nodes of the group.
A related problem is that because the backup effort is concentrated at a subset of the total number of nodes in the group, the backup process will take relatively longer than if all the nodes in the group were utilized for the backup process. While manual rescheduling of the backup process may help to distribute the backup workload more efficiently, configuring and implementing a manual rescheduling process is time consuming and thus increases the amount of time required to complete the backup process.
A further problem concerns the fact that federated backups may rely on manual definition, such as by an administrator or other user, of the PSOL. However, the use of a manually generated PSOL is problematic because, once defined, it cannot easily be modified in response to changes in conditions that may occur during a backup procedure. To illustrate, if a failover or other problem should occur during the backup process that renders one of the nodes inaccessible or non-functional, no mechanism is provided to account for this change in conditions, and the user would have to manually reconfigure the PSOL in response to changing conditions in the group containing the nodes where the databases reside. This manual reconfiguration interrupts and slows down the backup process, thus reducing availability of databases and/or nodes in the group.
In light of the foregoing, it would be helpful to be able to be able to balance a backup workload amongst the nodes in a group such as a database availability group (DAG). Likewise, it would be useful to be able to reconfigure a PSOL automatically in response to the occurrence of one or more events affecting an associated backup process.